Electronic design automation (EDA) systems provide software tools in which electronic circuit designs can be described, simulated, and translated by machine into a design realization. A conventional mechanism for describing a circuit design is hardware description language (HDL). A user defines a behavioral description of a design using HDL and the HDL design is processed to generate a physical implementation. HDL design tools include HDL simulation environments, such as the ModelSim environment from the Model Technology Company, and implementation environments, such as Synplify from Synplicity, Inc. Another type of circuit design system, referred to as a high level modeling system (HLMS), provides a higher level of abstraction for describing and simulating an electronic circuit than does an HDL simulation environment or implementation environment. An HLMS generally provides a mathematical representation of signals as compared to standard logic vectors in an HDL. It is desirable for the high-level abstractions to be precisely correlated with the ultimate implementation representation, both in simulation semantics and in implementation. The Xilinx System Generator tool for DSP and the MathWorks' Simulink and MATLAB environments are example HLMS's in which such capabilities are desirable.
Conventionally, HLMS's have often been used to specify systems that are easily expressed as data flow diagrams (e.g., digital filters). As HLMS's mature, designers are seeking to incorporate larger systems into an HLMS design, such as video-processing engines (e.g., MPEG encoders and decoders) and system-on-chip (SoC) designs, for example. Such designs may include instances of embedded instruction processors. In both HLMS and HDL environments alike, some type of communication protocol and connection medium must be used to interface a custom data processor with an instruction processor. For local connections, some form of a bus structure is typically employed to provide an interface between the custom data processor and the instruction processor. For non-local connections, a packet-based mechanism may be used, such as transmission control protocol/internet protocol (TCP/IP).
Interfacing custom logic blocks (e.g., a custom data processor) with instruction processors is tedious, error prone, and requires in-depth knowledge of traditional hardware design flow, instruction processor architectures, and traditional software design methodologies. The barrier to using instruction processors is further exacerbated by the plethora of instruction processor types and buses a designer may choose. The root of the problem is that custom logic blocks tend to be data-bound and, by that nature, predominately process data. Instruction processors predominately process instructions and, as such, require significantly more control logic and signals. Interfacing these two kinds of processors requires hardware interfaces and software drivers to bridge the hardware-software divide, and the creation of these interfaces and drivers is often difficult. Further, when a designer has designed hardware that is attached to a bus architecture, that logic is now tied to that specific architecture. Porting the design to operate with another bus architecture is at best tedious, and often arduous.
Accordingly, there exists a need in the art for a method and apparatus for interfacing instruction processors and user logic in an electronic circuit modeling system.